The secure sockets layer (SSL) trust model on the relying party (for example, a client) side faces challenges due, for example, to the growing list of trusted root certificate authorities (CAs) that are permitted to issue certificates for sub-CAs, which, in turn, issue certificates to web servers. If any root CA or sub-CA becomes compromised, the trust that a relying party can put into a web server certificate is severely compromised.
Existing alternate trust management approaches include requiring multiple notaries to validate an SSL server and/or monitoring changes in the certificate used by a server. However, such existing approaches fail to address aspects such as the behavior and/or experience level of the relying party user. For example, an experienced user might distrust a notary or research whether a certificate change is valid, whereas as a lesser experienced user may simply ignore a certificate trust warning. As such, it can be disadvantageous to leave such a decision in the exclusive control of the relying party user.
Additionally, existing alternative SSL trust models do not include means for the entity hosting or managing an SSL server to communicate to the relying party the particular trust model being used (for example, traditional, multiple notaries, etc.). As such, the relying party may be unaware of the trust model being used. Alternatively, even if an SSL certificate contains a marker informing the relying party to validate against multiple CAs, an attacker can potentially replace this certificate with a certificate for a compromised CA that follows a different trust model.
Accordingly, a need exists for techniques for communicating a chosen trust model to a relying party such that the relying party can subsequently validate the trust model.